Maximilian Tyrtania schrieb:
> Stimmt. Ich meine mich erinnern zu können, wie Tom Lane auf der
> general-Liste zu dem Thema mal sagte, dass Oracle zu einem Zeitpunkt
> entstand, als die filesysteme noch nicht so ausgereift waren wie heute =
und
> die Entwickler deswegen viel von dem, was ein modernes filesystem leist=
en
> kann, in die db eingebaut haben. Postgres ist jünger, und bedient sic=
h
> unbefangen aus den (mittlerweile luxuriösen) filesystem-APIs, sozusag=
en.
Tja, wenn das stimmt, dann sollten solche Test nicht solche Ergebnisse
erzielen, denn hier sind es
gerade die neuen Filesysteme mit Journaling (in diesem Fall EXT3) die
Postgres ganz gewaltig ausbremsen
können, wie diese Messung zeigt:

http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_t hat_performan=
ce_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresq l/

Im offiziellen PostgreSQL Performanceguide heisst es sogar noch präzise=
r:

POSTGRESQL usually performs best on traditional Unix file systems like
the BSD UFS/FFS filesystems, which many operating systems support.
The default 8K block size of UFS is the same as POSTGRESQL's page size.

http://www.postgresql.org/files/documentation/books/aw_pgsql /hw_performan=
ce/node11.html

Zum Thema ORACLE IFS Timeline gibt es auch einiges zu korrigieren. Das
Projekt IFS wurde
24.April 2000 als Erweiterung der damals aktuellen Oracle 8i Datenbak
erstmalig released

http://www.heise.de/newsticker/suche/ergebnis/?rm=3Dresult;q =3Difs;url=3D=
/newsticker/meldung/9459/;words=3DIFS
(und nicht in den Anfangstagen von Oracle)






--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

rudi [at] je-more.de wrote:

>> Stimmt. Ich meine mich erinnern zu können, wie Tom Lane auf der
>> general-Liste zu dem Thema mal sagte, dass Oracle zu einem Zeitpunkt
>> entstand, als die filesysteme noch nicht so ausgereift waren wie heute=

>> und
>> die Entwickler deswegen viel von dem, was ein modernes filesystem leis=
ten
>> kann, in die db eingebaut haben. Postgres ist jünger, und bedient si=
ch
>> unbefangen aus den (mittlerweile luxuriösen) filesystem-APIs, sozusa=
gen.
> Tja, wenn das stimmt, dann sollten solche Test nicht solche Ergebnisse
> erzielen, denn hier sind es
> gerade die neuen Filesysteme mit Journaling (in diesem Fall EXT3) die
> Postgres ganz gewaltig ausbremsen
> können, wie diese Messung zeigt:

Besser als Hauptabendprogramm hier...

Ja, wenn die Datenbank direkt auf ein Blockdevice schreibt (und dafür
optimiert ist!) wird man in nahezu allen Fällen flotter sein als wenn
man über eine FS-Abstraktionsebene geht (ich glaub das kann man sogar
mathematisch/logisch Beweisen wenn man möchte).

Ja, wenn die Datenbank direkt auf ein Blockdevice schreibt verliert man
viel an Flexibilität die man mit einem Filesystem drüber hätte.

Ja, wenn die Datenbank direkt auf ein Blockdevice schreiben soll, muss
man verdammt viel mehr Code pflegen als wenn man sich für viele
Teilbereiche auf den Kernel, der POSIX-genügende Funktionen zur
Dateimanipulation bereitstellt, verlässt.

Ja, wenn die Datenbank direkt auf ein Blockdevice schreiben soll, muss
man deutlich mehr Logik einbauen (und erst mal testen!), damit die Daten
auf dem Blockdevice konsistent sind.


Oracle hat die Arbeit investiert direkten Blockdevice-Support
einzubauen. Damals hat das wahrscheinlich auch Sinn gemacht, weil Oracle
"schon ein Zeiterl" Datenbanken macht, und bei vielen Betriebssystemen
bei unterschiedlichen Lastmustern die Performance unter aller Sau war
oder man im Produktiv-Betrieb unter Last fröhlich auf (V)FS-Bug-Jagd
gegangen ist. (Dieser Absatz beruht lediglich auf Mutmaßungen).

Oracle kann sichs auch leisten, weil die einen nicht zu verachtenden
Entwicklerstab haben.

Wenn du bei einem Opensourceprojekte fragst "Wollt ihr die Codebasis im
Persistence-Bereich verdoppeln um unter gewissen Umständen $n%
Mehrleistung rauszuholen als mit einem sinnvollen Filesystem- und
Blockdevice-Setup" wird die Antwort wohl relativ eindeutig ausfallen.



Und wenn ich dir noch länger die Welt erklären soll, muss ich wohl
langsam Anfangen Rechnungen auszustellen ;).


lg,
michael

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein